Method and system for facilitating micropayments in a financial transaction system

ABSTRACT

A system for processing accounts includes a database configured to store a plurality of accounts, the accounts including a consumer account associated with a consumer and a plurality of merchant accounts including a transacting merchant account associated with a merchant, wherein at least one account includes an amount of a virtual currency associated with the account. The system further includes a processor configured to process a financial transaction, wherein the transaction includes the consumer and the merchant, is for a specified amount of virtual currency, and processing the transaction includes transferring the specified amount of virtual currency from the consumer account to the transacting merchant account. The processor is further configured to process the at least one account, wherein processing the at least one account includes converting the associated amount of virtual currency to or from a real currency when the at least one account meets a predetermined criteria.

FIELD

The present disclosure relates to technical solution to providingvirtual currency micropayments, particularly as applied in a financialtransaction system, specifically utilizing a universal virtual currencyin order to minimize processing fees and times while facilitatingmicropayments.

BACKGROUND

In traditional financial transactions, consumers often used cash orpersonal checks in order to pay merchants for goods or services. Overtime, credit cards and other types of payment cards gained mainstreamuse. However, using a payment card may require the consumer, merchant,or both to pay a processing fee to a payment processor for processingpayment across traditional payment network process paths, i.e., paymentrails. Because of the existence of processing fees, some merchants set aminimum transaction amount that is required when a payment card is used.Merchants might accumulate small charges over a period of time, but itis not uncommon for the accumulated amount to still be small and thetransaction fees erode the value of the transaction for the party payingthe fees.

At the same time, consumers are entering more and more financialtransactions with merchants for smaller and smaller amounts. Thesemicropayment transactions will at times be for a payment amount that issmall and even less than the costs of processing the transaction, suchas transactions for things like digital music and other content thatmight be worth less than a dollar or even pennies. This can result in ahigher expense to the consumer, higher costs for the merchant, loss ofrevenue to payment processors, or others depending on the circumstances.Some merchants have taken to using an alternative currency fortransactions for their own transactions, and exchanging the alternativecurrency with real currency in commercially acceptable amounts, as tominimize processing costs. For instance, a consumer might buy a certainnumber of points (e.g., Microsoft Points™) or virtual currency (e.g.,Linden Dollars™) for a set number of real dollars, with the points orvirtual currency being available for purchases associated with themerchant or being limited to a particular merchant or merchant family orassociation (e.g., Discover Coins). This is a form of prepayment.

However, such systems often leave a consumer with residual alternativecurrency that they will not use. In addition, multiple merchants withunique alternative currencies can be confusing and hard to manage forconsumers, who must be aware of different exchange rates, values,purchase denominations, amount they have prepurchased, and more.Further, if a consumer utilizes multiple alternative currencies,residual amounts of each currency can compound into a large monetaryloss for the consumer. The inventors perceive there is a demand for atechnical solution to the problems presented by the commercial need formaking virtual currency, and in particular, micropayments available atan acceptable cost, particularly one accepted across multiple merchants.Further, the conversion between virtual currency and real currency isproblematic, requiring specific software that is generally specific to amerchant, merchant family, or association. What is perceived to beneeded is a technical solution so that virtual currency can be usedacross broad segments of the world economy by a central and/or worldwiderecognized entity to make it a cross-border, universal, or worldwideuniversal virtual currency.

SUMMARY

The present disclosure provides a description of methods and systems forprocessing financial accounts. More specifically, for methods andsystems for processing financial accounts that includes facilitatingmicropayments that utilizes a universal virtual currency for processingfinancial transactions between a consumer and multiple merchants.

A system for processing financial accounts includes a databaseconfigured to store a plurality of accounts, the plurality of accountsincluding a consumer account associated with a consumer and a pluralityof merchant accounts including a transacting merchant account associatedwith a merchant, wherein the consumer account and the transactingmerchant account each include an amount of virtual currency associatedwith the account. The system further includes a receiving deviceconfigured to receive a transaction request for a financial transactionbetween the consumer and the merchant, where the transaction requestincluding the consumer account, the merchant account, and a transactionamount of virtual currency. The system also includes a processorconfigured to: approve or deny the transaction request based on at leastthe amount of virtual currency associated with the consumer account andthe transaction amount of virtual currency; transfer the transactionamount of virtual currency from the consumer account to the merchantaccount upon approval of the transaction; and process the consumeraccount or the merchant account, wherein the processing includesconverting at least part of the associated amount of virtual currencyinto a real currency when the accounts meets a predetermined criteria.The system further includes a transmitting device configured to transmitthe approval or denial of the transaction request.

A method for processing financial accounts includes storing, in adatabase, a plurality of accounts, the plurality of accounts including aconsumer account associated with a consumer and a plurality of merchantaccounts including a transacting merchant account associated with amerchant, wherein the consumer account and the transacting merchantaccount each include an amount of virtual currency associated with theaccount. The method further includes receiving a transaction request fora financial transaction between the consumer and the merchant, where thetransaction request including the consumer account, the merchantaccount, and a transaction amount of virtual currency, and approving ordenying the transaction request based on at least the amount of virtualcurrency associated with the consumer account and the transaction amountof virtual currency. The method also includes transferring thetransaction amount of virtual currency from the consumer account to themerchant account upon approval of the transaction, processing theconsumer account or the merchant account, wherein the processingincludes converting at least part of the associated amount of virtualcurrency into a real currency when the accounts meets a predeterminedcriteria, and transmitting the approval or denial of the transactionrequest.

A system for processing financial transactions includes a receiverconfigured to receive a transaction request for a financial transactionwhere the transaction request includes at least information associatedwith a consumer, information associated with a merchant, and atransaction amount, and a database configured to store accountinformation including consumer account information corresponding to theconsumer and merchant account information corresponding to the merchant,each account information including an associated value of a universalvirtual currency, the universal virtual currency being able to beexchanged for a real currency. The system also includes a databaseconfigured to store at least one processing rule defining rules orguidelines for how to process the financial transaction and a processorconfigured to process the financial transaction in accordance with theat least one processing rule, wherein processing the financialtransaction includes adjusting the associated value of universal virtualcurrency in the consumer account information and the merchant accountinformation based on the transaction amount. The system further includesa transmitting component configured to transmit a response to thetransaction request, the response including at least a notification ofsuccess or failure of the processing of the financial transaction.

A method of processing financial transactions includes a receiving atransaction request for a financial transaction where the transactionrequest includes at least information associated with a consumer,information associated with a merchant, and a transaction amount, andstoring, in a database, account information including consumer accountinformation corresponding to the consumer and merchant accountinformation corresponding to the merchant, each account informationincluding an associated value of a universal virtual currency, theuniversal virtual currency being able to be exchanged for a realcurrency. The method also includes retrieving, from a plurality ofprocessing rules, at least one processing rule defining rules orguidelines for how to process the financial transaction and processing,by a processor, the financial transaction in accordance with the atleast one processing rule, wherein processing the financial transactionincludes adjusting the associated value of universal virtual currency inthe consumer account information and the merchant account informationbased on the transaction amount. The method further includestransmitting a response to the transaction request, the responseincluding at least a notification of success or failure of theprocessing of the financial transaction.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

Exemplary embodiments are best understood from the following detaileddescription when read in conjunction with the accompanying drawings. Itis emphasized that, these are exemplary embodiments, to which theclaimed invention is not limited. Included in the drawings are thefollowing figures:

FIG. 1 is a block diagram illustrating a system for facilitating paymentcard transactions in accordance with exemplary embodiments.

FIG. 2 is a block diagram illustrating a system for processing paymentcard transactions using a payment processor in accordance with exemplaryembodiments.

FIG. 3 is a block diagram illustrating a payment processing serverconfigured to process financial accounts in accordance with exemplaryembodiments.

FIG. 4 is a block diagram illustrating an exemplary system forprocessing financial accounts in accordance with exemplary embodiments.

FIGS. 5A and 5B are flow diagrams illustrating a process for processingfinancial transaction using a universal virtual currency in accordancewith exemplary embodiments.

FIGS. 6A-6C are illustrations of a graphical user interface for engagingin a micropayment transaction processed by the system of FIG. 3, inaccordance with exemplary embodiments.

FIG. 7 is an illustration of a graphical user interface for providingconsumer notification of a micropayment transaction in accordance withexemplary embodiments.

FIG. 8 is a block diagram illustrating an exemplary system forprocessing financial accounts in a consumer-to-consumer transaction inaccordance with exemplary embodiments.

FIGS. 9A-9D are illustrations of a graphical user interface fortransferring or receiving virtual currency processed by the system ofFIG. 3, in accordance with exemplary embodiments.

FIGS. 10 and 11 are flowcharts illustrating an exemplary method forprocessing financial accounts in accordance with exemplary embodiments.

FIG. 12 is a flowchart illustrating an exemplary method for processingfinancial transactions in accordance with exemplary embodiments.

Further areas of applicability of the present disclosure will becomeapparent from the detailed description provided hereinafter. It shouldbe understood that the detailed description of exemplary embodiments areintended for illustration purposes only and are, therefore, not intendedto necessarily limit the scope of the disclosure.

DETAILED DESCRIPTION Legacy Payment Card Transaction System

FIG. 1 is a block diagram illustrating a system 100 for processingpayment card transactions. A consumer 102 may engage in a financialtransaction (e.g., a transaction for the purchase of goods or services)with a merchant 104. The transaction may occur at a physical location ofthe merchant 104, or may be performed remotely, such as through theInternet, over telephone, by mail order, or by any other method suitablefor financial transactions.

The consumer 102 may use a payment card in order to facilitate paymentfor the financial transaction. The payment card may be any type oftransaction card used for making payments in a financial transaction,such as a debit card, credit card, charge card, ATM card, etc. Eachpayment card may be assigned a unique identifier (e.g., an accountnumber) that links the payment card to the cardholder (e.g., theconsumer 102).

The payment card may be issued to the consumer 102 by an issuer 108,such as a bank. The issuer 108 may assign the consumer 102 a uniqueidentifier (e.g., an account number). The consumer 102 may have multiplepayment cards issued by the issuer or issuers 108, or may have otherfinancial accounts (e.g., checking accounts, savings accounts, etc.(collectively known as funding sources)). Each of the payment cards orfinancial accounts may be associated with the unique identifier assignedto the consumer 102.

The merchant 104 may provide transaction information (e.g., payment cardinformation, transaction amount, etc.) for the financial transaction toan acquirer 106, such as the merchant's bank. The acquirer 106 maycommunicate with the issuer 108 to process the financial transaction.The acquirer 106 may submit an authorization request to the issuer 108that issued the payment card used in the transaction (e.g., thecardholder's bank). The issuer 108 may approve or deny the transaction.If the issuer 108 approves the transaction, the issuer 108 may notifythe acquirer 106 of the approval. The acquirer 106 may then notify themerchant 104 of the approval of the transaction, who may then finalizethe transaction with the consumer 102. The issuer 108 may then bill theconsumer 102 for payment of the transaction.

In an exemplary embodiment, the system 100 may also include a paymentprocessor 110 (illustrated in FIG. 2). The payment processor 110 mayprocess the payment card transaction on behalf of the acquirer 106and/or the issuer 108. The payment processor 110 may be any serviceprovider for merchants, acquirers, issuers, consumers, etc. for theprocessing transactions involving payment cards, such as MasterCard,VISA, American Express, etc. The payment processor 110 may charge a feeto the merchant 104 for the processing of the financial transaction(e.g., processing money across traditional payment rails, as definedbelow). The fee may be a per-transaction fee, a set fee, a variable fee,or any other fee scheme suitable for the processing of financialtransactions.

FIG. 3 illustrates a block diagram of a payment processing server 210,which may be configured to perform as the payment processor 110. Thepayment processing server 210 may be a single server, or may include aplurality of servers networked together (e.g., physically, such as by acoaxial cable, or wirelessly, such as through a local area network).Components of the payment processing server may be connected via a bus312, types of which will be apparent to persons having skill in therelevant art. The payment processing server 210 may include a processingunit 302. The processing unit 302 may be any processor configured toperform the functions disclosed herein, such as a single centralprocessing unit (CPU) or multiple CPUs. Suitable types andconfigurations of processing units will be apparent to persons havingskill in the relevant art.

The payment processing server 210 may also include a memory 304. Thememory 304 may be a random access memory (RAM), a read-only memory(ROM), or a combination thereof. The memory 304 may store a program thatmay cause the processing unit 302 to perform functions as disclosedherein. The payment processing server 210 may also include aninput/output (I/O) unit 306. The I/O unit 306 may transmit or receiveinformation, such as an authorization request or a reply to anauthorization request (e.g., to the acquirer 106). The I/O unit 306 maycommunicate with entities outside of the payment processor 110 (e.g.,the issuer 108) by utilizing a communications unit 308. Thecommunications unit 308 may be configured to facilitate communicationthrough a network, such as network 116, discussed in more detail below.

The payment processing server 210 may also include a database 310. Thedatabase 310 may be included as part of the payment processing server210 or may be external to the payment processing server 210 and accessedvia a network (e.g., the network 116). The database 310 may be a singledatabase, or be comprised of multiple databases, which may be internalto the payment processing server 210 or external and accessed via anetwork, or a combination thereof.

Data may be stored on any type of suitable computer readable media, suchas optical storage (e.g., a compact disc, digital versatile disc,Blu-ray disc, etc.) or magnetic tape storage (e.g., a hard disk drive).The database 310 may be configured in any type of suitable databaseconfiguration, such as a relational database, a structured querylanguage (SQL) database, a distributed database, an object database,etc. Suitable configurations and storage of the databases will beapparent to persons having skill in the relevant art.

The database 310 may be configured to store a plurality of accounts,including a consumer account and a plurality of merchant accounts. Theconsumer account may be associated with a consumer (e.g., the consumer102). At least one of the plurality of merchant accounts may beassociated with a merchant (e.g., the merchant 104). At least oneaccount of the plurality of accounts may include an amount of virtualcurrency, as discussed below, associated with the account. In oneembodiment, each account of the plurality of accounts includes anassociated amount of virtual currency.

In some embodiments, the consumer account associated with the consumer102 may also be associated with a payment card (e.g., the payment cardused in the financial transaction), or other accounts associated withthe consumer (e.g., additional payment cards, checking accounts, savingsaccounts, etc.). In one embodiment, the consumer 102 may select apreferred payment card or other account to be used by the paymentprocessor 110 when processing financial transactions including theconsumer 102.

Processing Financial Accounts and Micropayment Transactions

Due to the expenses incurred with processing financial transactionsacross traditional payment rails (e.g., Automated Clearing House (ACH),wire transfers, etc.), payment processors (e.g., the payment processor110) may charge fees, such as to the merchant 104 or the merchant'sacquiring bank (e.g., the acquirer 106), for each transaction processed.In some instances, the fee for processing a financial transaction mayrival or even be greater than the value of the product. For micropaymenttransactions, financial transactions of amounts that are small (e.g.,fractions of a standard unit of currency, such as transactions less thana U.S. dollar, for 3-5 cents, or even fractions of cents), the addedexpense of processing fees may cause the merchant 104 to lose asignificant amount of revenue when payment cards are used to pay formicropayment transactions. The present payment technical solution,however, is not limited to micropayments, but rather, offers thepossibility of a universal virtual currency for transactions ofpotentially any size or value. It, in essence, offers a universalvirtual currency.

A universal virtual currency (UVC) may provide an opportunity forminimizing processing fees, while maintaining existing payment andprocessing structures. The use of a universal virtual currency may limitthe amount of real currency that is moved across traditional paymentrails and thus reduce processing cost. In an exemplary embodiment, theuniversal virtual currency may be used in financial transactions withlimited, if any, modification to existing hardware and software of theconsumer 102 and the merchant 104.

FIG. 4 illustrates a system 400 for processing financial accounts andmicropayment transactions utilizing a universal virtual currency. Thesystem 400 may include the consumer 102, who may use a device (e.g., apersonal computer, a mobile communication device, etc.) to navigate to awebpage of the merchant 104, which may be hosted on or accessed througha web server 112. The web server 112 may communicate with the consumer102 and/or the merchant 104 through a network 116. Networkconfigurations that may be suitable for performing the functions asdisclosed herein may include a local area network (LAN), a wireless areanetwork (WAN), WiFi, coaxial cable, fiber optic, the Internet, infrared,radio frequency, combinations thereof, or other configurations that willbe apparent to persons having skill in the relevant art.

The consumer 102 may initiate a financial transaction with the merchant104 (e.g., through the web server 112). The financial transaction may bea micropayment transaction. In an exemplary embodiment, the micropaymenttransaction is for an amount of universal virtual currency (e.g., 5 UVCor “bubbles”). In one example, the corresponding amount of correspondingreal currency is less than the processing fee required for a paymentprocessor (e.g., the payment processor 110) to process the financialtransaction. When the consumer 102 initiates the financial transactionwith the merchant 104, the web server 112 may communicate with thepayment processing server 210 to carry out the transaction. In oneembodiment, the web server 112 may transmit transaction data (e.g.,consumer information, merchant information, transaction details,transaction amount, etc.) to the payment processing server 210. In oneembodiment, the transaction data may be transmitted pursuant to theInternational Organization for Standardization's ISO 8583 standard.

The payment processing server 210 may process the micropaymenttransaction using universal virtual currency. In an exemplaryembodiment, the payment processing server 210 may process thetransaction without using traditional payment rails. The paymentprocessing server 210 may identify a consumer account in the database310 associated with the consumer 102, and a merchant account in thedatabase 310 associated with the merchant 104. The consumer account andthe merchant account may include an amount of universal virtual currencyassociated with each account.

The payment processing server 210 may process the micropaymenttransaction by transferring an amount of UVC equal to the amount of thetransaction from the consumer account to the merchant account. In anexemplary embodiment, the payment processing server 210 does not processany amount of real currency. In one embodiment, the processing of thetransaction does not use any traditional payment rails.

In one embodiment, the payment processing server may process themicropayment transaction based on rules or guidelines defined by acorresponding processing rule. The processing rule may be included in aplurality of processing rules, which may be stored in the database 310.The plurality of processing rules may each define rules or guidelinesfor processing the corresponding financial transaction. For example,there may be different processing rules for each merchant, for eachconsumer, for transactions that require currency exchange, based on thetransaction amount, based on the location of the merchant and/or theconsumer, etc. Rules or guidelines defined by processing rules mayinclude rules for approving the transaction, for denying thetransaction, rules or guidelines for adjusting the value of universalvirtual currency in the associated account or accounts, rules forperforming currency exchanges, or any other rule or guideline forprocessing a financial transaction as will be apparent to persons havingskill in the relevant art.

The payment processing server 210 may notify the web server 112, themerchant 104, or the consumer 102 of the success or failure (e.g., ifthe consumer account does not contain enough UVC) of the micropaymenttransaction. If the micropayment transaction processing is complete, themerchant 104 and/or the web server 112 may finalize the transaction. Inone embodiment, the payment processing server 210 may notify theconsumer 102 of the transaction on a consumer device 114 associated withthe consumer 102, such as a mobile communication device (e.g., a cellphone, smart phone, tablet computer, etc.). In another embodiment, thepayment processing server 210 may transmit an electronic mail message(e-mail) to an e-mail account associated with the consumer (e.g., andstored in the database 310 and associated with the consumer account).

In an exemplary embodiment, the universal virtual currency may beaccepted by a plurality of merchants (e.g., associated with theplurality of merchant accounts stored in the database 310). Managing ofUVC account information by the payment processor 110 may result in lessexpense and resources necessary by the plurality of merchants (e.g., themerchant 104) in utilizing the universal virtual currency. In someembodiments, the universal virtual currency may be used in existingtransaction systems.

The payment processing server 210 may also be configured to processfinancial accounts (e.g., stored in the database 310), such as theconsumer account associated with the consumer 102 or the merchantaccount associated with the merchant 104. The payment processing server210 may process a financial account by converting an amount of universalvirtual currency associated with the financial account to real currency.In an exemplary embodiment, the universal virtual currency may beconverted to real currency only when the account meets a predeterminedcriteria.

In one embodiment, the predetermined criteria may be set by the consumeror merchant associated with the account. In another embodiment, thepredetermined criteria may be set by the payment processor 110, or bythe merchant's acquiring bank (e.g., the acquirer 106) or the consumer'sissuing bank (e.g., the issuer 108). In one embodiment, thepredetermined criteria may be that the corresponding amount of realcurrency is of a minimum amount. In a further embodiment, the minimumamount of real currency is the fee for processing (e.g., transferring)the real currency to the consumer or merchant associated with theaccount. In another embodiment, the predetermined criteria may betime-based (e.g., universal virtual currency is automatically convertedto real currency and distributed to the account holder on the first ofevery month).

In some embodiments, the converted real currency may be associated withthe same financial account. In other embodiments, the converted realcurrency may be associated with a different financial account (e.g.,still associated with the consumer or merchant). In some instances, theholder of the account of the universal virtual currency may elect adestination account for the real currency (e.g., a checking account, apayment card account, etc.).

Processing financial accounts may also include converting real currencyinto universal virtual currency. For example, the payment processingserver 210 may be configured to process a purchase by the consumer 102for a specified amount of virtual currency for a corresponding amount ofreal currency. In some embodiments, the consumer 102 may be required tospend a minimum amount of real currency. In a further embodiment, theminimum amount of real currency may be at least the fee for processingthe transaction. In some embodiments, the consumer may select apurchasing method (e.g., from an account with the payment processor 110,a payment card, a checking account, etc.).

Micropayment Transaction Processing Flow

FIGS. 5A and 5B illustrate an exemplary processing flow for processing amicropayment transaction using a universal virtual currency.

In step 502, a user (e.g., the consumer 102) may shop with the merchant102 (e.g., on a website of the merchant 104 or at a physical location ofthe merchant 104) and choose to checkout. In step 504, the merchant 104may send transaction details to the payment processing server 210, whichmay receive (e.g., and store, such as in the database 310) thetransaction details in step 506. The transaction details may includemerchant identifying information, consumer identifying information, anda transaction amount. In one embodiment, the transaction data may betransmitted pursuant to the International Organization forStandardization's ISO 8583 standard.

In step 508, the payment processing server 210 may prompt the consumer102 for authentication information. Authentication information mayinclude an e-mail address, a username, a password, a personalidentification number, or any other information necessary to validatethe identity of the consumer 102. The prompt for information may bedisplayed to the consumer in step 510. In one embodiment, the prompt forinformation may be displayed using the medium in which the consumer 102is engaging in the transaction (e.g., on the computer the consumer 102used to visit the webpage of the merchant 104). In another embodiment,the prompt for information may be displayed on a device associated withthe consumer (e.g., the consumer device 114).

In step 512, the consumer 102 may provide the authentication informationto the payment processing server 210, which, in step 514, may receivethe authentication information. The payment processing server 210 mayuse the received authentication information to retrieve accountinformation associated with the consumer 102 (e.g., and stored in thedatabase 310). The account information may include an amount ofuniversal virtual currency associated with the consumer 102, financialaccount information, funding sources, etc. In step 518, the paymentprocessing server 210 may transmit account and transaction details, suchas the merchant name, transaction amount, and amount of universalvirtual currency associated with the consumer 102, to the consumer 102.In some embodiments, the transmitted details may also include a fundingsource previously identified by the consumer 102. In step 520, thereceived account and transaction details may be displayed to theconsumer 102.

In step 522, the consumer 102 may request additional virtual currency tofund their account from the payment processing server 210. In oneembodiment, the request for additional virtual currency may include auniversal currency amount, a real currency amount, or a funding source.The payment processing server 210 may receive the funding requestdetails in step 524, and, in step 526, process the funding request andupdate the account associated with the consumer 102 (e.g., by increasingthe amount of associated universal virtual currency) upon completion ofthe processing. In step 528, the updated account details may betransmitted by the payment processing server 210 to the consumer 102,which may display the updated account details in step 530. It will beapparent to persons having skill in the relevant art that steps 522-530may be optional. For example, if the consumer 102 has an adequate amountof universal virtual currency in their account, it may not be necessaryto purchase additional universal virtual currency.

In step 532, the consumer 102 may confirm the transaction. The paymentprocessing server 210 may receive the confirmation in step 534, and, instep 536, may process the transaction using universal virtual currency.Processing the transaction may include transferring an amount ofuniversal virtual currency (e.g., the transaction amount) from anaccount associated with the consumer 102 to an account associated withthe merchant 104. In step 538, the payment processing server 210 mayapprove the transaction and notify the merchant 104 and the consumer102. The approval may be displayed to the consumer 102 (e.g., on theclient device 114) in step 540. In step 542, the approval may bedisplayed to the merchant 104, and, in step 544, the merchant 104 maycomplete the transaction.

Exemplary Graphical User Interface for Micropayment Transactions

FIGS. 6A-6C illustrate a graphical user interface for a consumer (e.g.,the consumer 102) engaging in a micropayment transaction.

In FIG. 6A, the consumer 102 may navigate to a webpage 602, which may beaccessed through a web server (e.g., the web server 112). The webpagemay be owned or maintained by a merchant (e.g., the merchant 104). Theconsumer 102 may be presented with goods or services for purchasing. Agood or service that is available may be accompanied by a method ofinitiating a financial transaction for the good or service, such as the“pay now” button 606. The consumer 102 may interact with the “pay now”button 606 to initiate the micropayment transaction.

Upon interacting with the button 606, the consumer 102 may be presentedwith a transaction window 608 (as illustrated in FIG. 6B). The consumermay be required to submit information to identify the consumer, such asauthentication information 610. The authentication information 610 maybe any information necessary for the payment processor 110 to identifythe consumer account associated with the consumer 102. In an exemplaryembodiment, the authentication information may also include a passwordor other information (e.g., a personal identification number) for thepurposes of account and consumer security. In one embodiment, theconsumer 102 may also provide information specific to the merchant 104,such as loyalty program or rewards information.

When the consumer 102 has furnished the proper information, the consumer102 may interact with a login button 612. The authentication informationmay be submitted to the web server 112, who may authenticate the user asthe consumer 102 (e.g., by communicating with or providing theinformation to the payment processor 110). If the authentication fails,the user may be notified of the failure (e.g., in the transaction window608).

FIG. 6C illustrates the transaction window 608 which may be presented tothe consumer 102 if authentication is successful. The consumer 102 maybe provided with information that may be useful in proceeding with themicropayment transaction. For example, the consumer 102 may be presentedwith an account balance 614, indicating the amount of universal virtualcurrency currently associated with the consumer account associated withthe consumer 102. The transaction window 608 may also include atransaction amount 516, indicating the amount of universal virtualcurrency the consumer 102 must pay to complete the transaction (e.g., 5UVC, or “bubbles”, as illustrated in FIG. 6C).

In one embodiment, the transaction amount 616 may indicate discounts orpromotions applied to the expense of the transaction (e.g., due to aloyalty program, coupon, etc.). The transaction window 608 may furtherinclude payee information 618, which may indicate the merchantassociated with the merchant account. In some instances, the payeeinformation 618 may include the merchant 104. If the consumer 102 wishesto complete the financial transaction, the consumer 102 may interactwith the “yes” button 618, which may initiate processing of themicropayment transaction (e.g., with the web server 112 and/or thepayment processor 110).

The payment processor 110 may process the micropayment transaction, asdescribed above. The payment processor 110 may notify the consumer 102of the authorization or denial of the transaction. In one embodiment,the consumer 102 may be notified in the transaction window 608. Inanother embodiment, the consumer 102 may be sent an e-mail message bythe payment processor 110 or a third party. In an exemplary embodiment,the consumer 102 may be notified by a transmission (e.g., a notificationvia short message service message, e-mail, automated or live voice mailor call, pop-up, etc.) to the consumer device 114 associated with theconsumer 102.

FIG. 7 illustrates a graphical user interface of the consumer device 114when receiving a notification of a successful micropayment transaction(e.g., from the payment processor 110). The consumer device 114 mayinclude a display 702, such as a light emitting diode (LED) display, aliquid crystal display (LCD), a capacitive touch display, or any othertype of display as will be apparent to persons having skill in therelevant art. The display 702 may be display a notification window 704.The notification window 704 may include any information suitable fornotifying the consumer 102 of the micropayment transaction. For example,the notification window 704 may include the transaction amount 616 orthe payee information 618.

Processing of Person-to-Person or Peer-to-Peer Transactions

The payment processor 110 may also be configured (e.g., through theprocessing server 210) to process peer-to-peer (e.g., person-to-person)transactions, such as transactions for the request or transfer ofuniversal virtual currency between two consumers. FIG. 8 illustrates asystem 800 for the processing of a universal virtual currency transferfrom the consumer 102 to a second consumer.

The consumer 102 may use the consumer device 114 (e.g., a smartphone) toinitiate a request for universal virtual currency. The consumer 102 mayinput transaction information, such as a name or unique identifier ofthe second consumer, a transaction amount, or description of therequest, into the consumer device 114. The information may betransmitted (e.g., through the network 116) to the payment processingsever 210. The payment processing server 210 may relay the request tothe second consumer via a second consumer device 118 (e.g., asmartphone).

The second consumer may accept or deny the request using the secondconsumer device 118. If the second consumer accepts the request, thepayment processing server 210 may process the request by transferringthe transaction amount of universal virtual currency from a consumeraccount associated with the second consumer (e.g., and stored in thedatabase 310) to a consumer account associated with the consumer 102.The payment processing server 210 may notify the consumer 102 and thesecond consumer via the devices associated with each consumer of theresults of the processing (e.g., by transmitting a notification asillustrated in FIG. 7).

In another embodiment, the consumer 102 may initiate a transfer ofuniversal virtual currency using the consumer device 114. The consumer102 may provide information, such as a unique identifier of the secondconsumer, transaction amount, and description, which may be transmittedto the payment processing server 210. The payment processing server 210may process the transfer and notify the consumer 102 (e.g., through theconsumer device 114) and/or the second consumer (e.g., through thesecond consumer device 118). In an exemplary embodiment, the transfermay be processed without using traditional payment rails.

FIGS. 9A-9D illustrate an exemplary graphical user interface forengaging in a financial transaction for the transfer of universalvirtual currency from a first consumer (e.g., the consumer 102) to asecond consumer.

FIG. 9A depicts an interface for an application program, which may berun on a device, such as a mobile communication device (e.g., theconsumer device 114). The application program may display an applicationwindow 902 (e.g., on the display 702). The application window 902 maydisplay a transaction history 908, which may include a history offinancial transactions associated with the user (e.g., the consumer102). In one embodiment, the transaction history 908 may include onlyuniversal virtual currency transactions.

The application window 902 may also include a transfer button 904. Uponuser interaction with the transfer button 904, the application window902 may present a transfer button 910, a request button 912, and acancel button 914. User interaction with the cancel button 914 mayremove the buttons 910, 912, and 914 from the application window (e.g.,and only display the transaction history 908). Interaction with therequest button 912 may display a screen requesting input of informationfor the request of universal virtual currency with a second consumer.

Interaction with the transfer button 910 may display the input screenillustrated in FIG. 9B. In FIG. 9B, the application window 902 maydisplay an input screen for the user (e.g., the consumer 102) to provideadditional information for a transfer of universal virtual currency. Forexample, the user may provide a payee identifier 916 (e.g., a uniqueidentification of the intended recipient) and a transfer amount 920. Insome embodiments, the user may provide a memo 922 with the transfer. Thememo 922 may be a personal note for user, or in some embodiments, mayalso be a useful note to the recipient when the funds are received (suchas explaining that the transfer is to repay a debt owed to therecipient).

The application window 902 may also include an addition button 916,which may allow the user to input unique identifiers for additionalpayee. This capability may be useful if the user wishes to transferuniversal virtual currency to multiple accounts or consumers at the sametime. The user may interact with a send button 924 in order to initiateprocessing of the transfer. Information (e.g., entered by the user inthe application window 902) may be transmitted to the payment processingserver 210, which may process the transfer of funds by methods disclosedherein. In an exemplary embodiment, the transfer may be processedwithout using traditional payment rails.

In some embodiments, the user may be required to provide confirmation ofthe transfer, such as in confirmation window 926 illustrated in FIG. 9C.In the confirmation window 926, the user may be able to confirm thetransfer and initiate processing by interacting with the send button928, or may cancel the transfer by interacting with cancel button 930(e.g., and returned to the input screen illustrated in FIG. 9B). Afterprocessing by the payment processing server 210 has been completed, theapplication window 902 may display a notification 932 of the completedtransfer, as illustrated in FIG. 9D.

Currency Exchanging

The payment processing server 210 may also be configured to process theexchanging of a first real currency to or from the universal virtualcurrency, or from the first real currency to or from a second realcurrency by using the universal virtual currency. The exchanging of realcurrency using a universal virtual currency may provide consumers withbetter control over fluctuations in exchange rates, and may provideconsumers with a more stable centralized currency to or from which othercurrencies may be freely exchanged.

FIG. 10 illustrates a method 1000 for processing a currency exchangefrom a real currency into a universal currency, and further into asecond real currency.

In step 1002, a processing server (e.g., the payment processing server210) may receive a currency conversion request (e.g., from the consumer102, the merchant 104, etc.). The currency conversion request mayinclude an amount of universal virtual currency to be obtained, anamount of first real currency for conversion, or an amount of secondreal currency to be obtained. In some embodiments, the paymentprocessing server 210 may require a minimum amount of first realcurrency, universal virtual currency, or second real currency (e.g., dueto the fees of processing real currency). In step 1004, the paymentprocessing server 210 may identify if funding source information issaved (e.g., in a profile associated with the requester, such as aprofile stored in the database 310). Funding source information mayinclude a payment card (e.g., a credit card), a checking account, orother funding source to be used to charge (e.g., for the amount of realcurrency identified) for the currency exchange. In some instances, thecurrency conversion request may include a funding source, which thepayment processing server 210 may save in a profile associated with therequester, at the requester's consent.

If funding information is not available, or if funding information maybe incomplete, then, in step 1006, the payment processing server 210 mayrequest and receiving funding source details (e.g., from the requester,an issuing bank, etc.). Once funding information has been received or isotherwise available to the payment processing server 210, then thepayment processing server 210 may process the first real currency intothe universal virtual currency in step 1008. Processing the realcurrency into universal virtual currency may include processing thefunding source for an amount of first real currency to be converted intouniversal virtual currency, and associating the corresponding amount ofuniversal virtual currency with the profile associated with therequester. The payment processing server 210 may use a defined currencyexchange rate for the conversion of the first real currency intouniversal virtual currency.

In some embodiments, the currency exchange rate may be a predefined rate(e.g., 1 U.S. dollar is always worth 100 UVC). In other embodiments, thecurrency exchange rate may be a fluctuating rate (e.g., based oninternational markets, currency value, etc.). Methods for determiningthe value of currency and ideal currency exchange rates will be apparentto persons having skill in the relevant art. The currency exchange ratemay be calculated on a regular basis (e.g., daily, weekly, hourly, etc.)or may be calculated in real-time at the time of the requested currencyconversion. In one embodiment, the currency exchange rate may bedependent on the amount of real currency being exchanged for universalvirtual currency.

In step 1010, the payment processing server 210 determines if theexchanged universal virtual currency is to be converted into a secondreal currency. In some instances, the determination may be based oninformation included in the currency conversion request. In otherinstances, the payment processing server 210 may query the requester todetermine if further conversion is requested (e.g., as part of the sameconversion transaction). If no further conversion is requested, then, instep 1012, the payment processing server 210 may notify the requester(e.g., the consumer 102) of the conversion. For example, the consumer102 may receive a short messaging service (SMS) message or anotification on the consumer device 114 (e.g., as illustrated in FIG.7). Information included in the notification may include, the approvalor denial of the conversion transaction, the amount of real currencyexchanged, the amount of universal virtual currency obtained, and thetotal amount of universal virtual currency associated with the consumer102.

If a further conversion of the universal virtual currency into a secondreal currency is requested, then, in step 1014, the payment processingserver 210 may identify if destination information (e.g., an account forthe deposit of the second real currency, such as a checking account) hasbeen provided. In some instances, destination account information may bepreviously saved (e.g., in a profile associated with the consumer 102and stored in the database 310). In other instances, the destinationaccount information may be included in the original conversion request,or in a response to a query prompted to the consumer 102 in step 1010.If no destination account information has been provided, then thepayment processing server 210 may request and receive the informationfrom the consumer 102 in step 1016.

In step 1018, the payment processing server 210 may process the exchangeof the universal virtual currency into the second real currency. Acurrency exchange rate may be used in determining the amount of secondreal currency to be obtained for the exchange of the universal virtualcurrency. The currency exchange rate may be based on the considerationsdiscussed above. Further, the currency exchange rate may be based on anexchange of the universal virtual currency to the second real currencyor may be based on an exchange of the first real currency to the secondreal currency, which may result in a different obtained amount of secondreal currency.

After the second currency exchange has been processed, the paymentprocessing server 210 may, in step 1020, notify the consumer 102 of theconversion (e.g., through a notification on the consumer device 114).The notification may include the approval or denial of the conversiontransaction, the amount of first real currency exchanged and the amountof second real currency obtained. The notification may also include theamount of universal virtual currency that was obtained and subsequentlyconverted as part of the conversion transaction.

In addition to exchanging real currency into universal virtual currencyor a second real currency, universal virtual currency may be exchangedinto real currency. The exchange of universal virtual currency into realcurrency may include, for example, step 1002 and steps 1010-1020 of themethod 1000. In some instances, the payment processing server 210 mayperform automatic conversions of universal virtual currency to realcurrency. For example, a merchant (e.g., the merchant 104) may requestthat its balance of universal virtual currency be converted to realcurrency and distributed to a financial account at the beginning ofevery month.

Exemplary Method for Processing Financial Accounts

FIG. 11 is a flowchart illustrating an exemplary method 1100 forprocessing financial accounts, including facilitating transactions usinga universal virtual currency.

In step 1102, a plurality of accounts are stored (e.g., in the database310) including a consumer account associated with a consumer (e.g., theconsumer 102) and a plurality of merchant accounts, including atransacting merchant account associated with a merchant (e.g., themerchant 104). At least one account of the plurality of accounts mayinclude an amount of virtual currency associated with the account. Insome embodiments, a consumer or merchant may be associated with multipleaccounts (e.g., one account per payment card or other funding source).In a further embodiment, each consumer or merchant may be assigned aunique identifier (e.g., a unique identification number).

In step 1104, a transaction request is received (e.g., by thecommunications unit 308 of the payment processing server 210 on behalfof the payment processor 110), the transaction request being for afinancial transaction between the consumer and the merchant, thetransaction request including the consumer account, the merchantaccount, and a transaction amount of virtual currency. In oneembodiment, the consumer account may include a unique identifier (e.g.,an account number) of an account corresponding to the consumer. In oneembodiment, the transaction data may be transmitted pursuant to theInternational Organization for Standardization's (IOS) ISO 8583 standardor a similar, suitable standard for communication transactioninformation.

In step 1106, a processor (e.g., the processing unit 302 of the paymentprocessing server 210) may approve or deny the transaction request basedon at least the amount of virtual currency associated with the consumeraccount and the transaction amount of virtual currency. In someembodiments, the financial transaction may be denied if the value ofvirtual currency associated with the consumer account is less than thetransaction amount of the transaction. In one embodiment, the approvalor denial of the transaction request may also be based on at least oneof: consumer information, merchant information, an exchange rate,location of the transaction, and time and/or date of the transaction.

In step 1108, the processing unit 302 may transfer the transactionamount of virtual currency from the consumer account to the merchantaccount upon approval of the transaction. In an exemplary embodiment,the transfer may not use traditional payment rails. In a furtherembodiment, traditional payments rails may include Automated ClearingHouse (ACH) and wire transfer. In some embodiments, the consumer and/orthe merchant may be notified of completion of the transfer of thevirtual currency.

In step 1110, the processing unit 302 may process the consumer accountor the merchant account, wherein processing includes converting at leastpart of the associated amount of virtual currency into a real currencywhen the account meets a predetermined criteria. In one embodiment, thepredetermined criteria may be set by a user associated with the account.In another embodiment, the predetermined criteria may be set by theprocessor (e.g., the payment processor 110). In yet another embodiment,the predetermined criteria may be a request from a user associated withthe account. In one embodiment, the predetermined criteria may be whenthe associated amount of virtual currency corresponds to a minimumamount of the real currency. In a further embodiment, the minimum amountof real currency may be the amount of real currency required to processthe financial transaction. In some embodiments, a unit of the realcurrency may correspond to a plurality of units of the virtual currency.In an exemplary embodiment, the predetermined criteria may be unrelatedto the financial transaction. In one embodiment, the converting step maybe performed using traditional payment rails.

In step 1112, the approval or denial of the transaction request may betransmitted (e.g., by the communications unit 308 of the paymentprocessing server 210). In some embodiments, the transmission of theapproval or denial of the transaction request may be performed pursuantto an IOS standard. In one embodiment, the approval or denial may alsoinclude additional information, such as the transaction amount, a timeand/or date of the transaction, or the updated value of associatedvirtual currency for the consumer and/or the merchant. It will beapparent to persons having skill in the relevant art that step 1112 maybe performed prior to or concurrently with step 1110.

Exemplary Method for Processing Financial Transactions

FIG. 12 illustrates an exemplary method 1200 for processing financialtransactions using a universal virtual currency.

In step 1202, a transaction request for a financial institution may bereceived (e.g., by the communications unit 308 of the payment processingserver 210). The transaction request may include at least informationassociated with a consumer, information associated with a merchant, anda transaction amount. In one embodiment, the information associated witha consumer may include a unique identifier for the consumer, such as anaccount number associated with the consumer. In an exemplary embodiment,the transaction amount may be a specific value of universal virtualcurrency.

In step 1204, a processing unit (e.g., the processing unit 302 of thepayment processing server 210) may identify (e.g., in a database, suchas the database 310) consumer account information corresponding to theinformation associated with the consumer and merchant accountinformation corresponding to the information associated with themerchant, with each account information including an associated value ofuniversal virtual currency. Then, in step 1206, the processing unit 302may retrieve from a plurality of processing rules a processing rulecorresponding to the financial transaction, the processing rule definingrules or guidelines for how to process the financial transaction. Insome embodiments, rules or guidelines may include rules or guidelinesfor authorizing a transaction, declining a transaction, calculatingtransaction amounts, calculating exchange rates, how or if notice shouldbe provided to any entities, or any other rules or guidelines forprocessing financial transactions as discussed herein.

In step 1208, the processing unit 302 may process the financialtransaction in accordance with the retrieved processing rule, theprocessing step including adjusting the associated value of universalvirtual currency in the consumer account information and the merchantaccount information based on the transaction amount. In an exemplaryembodiment, the processing step will not be performed using traditionalpayment rails. In one embodiment, the adjusting the associated value ofuniversal virtual currency may be further based on a currency exchangerate defined by the processing rule.

In step 1210, a response to the transaction request may be transmitted(e.g., by the communications unit 308 of the payment processing server210), the response including at least a notification of the success orfailure of the processing of the financial transaction. In oneembodiment, the response may also include at least one of the resultingvalue of universal currency associated with the consumer accountinformation or the merchant account information, a time and/or date ofthe financial transaction, the location of the transaction, or thetransaction amount.

In some embodiments, the method 1200 may further include steps forprocessing a consumer account. The communications unit 308 may receivean exchange request, the exchange request including at least theinformation associated with the consumer, a real currency, an exchangevalue, and account routing information. In one embodiment, theinformation associated with the consumer may include a unique accountidentifier associated with the consumer, such as an account number. Theprocessing unit 302 may retrieve a rate of exchange, the rate ofexchange defining an amount of the universal virtual currencycorresponding to an amount of the real currency. In one embodiment, therate of exchange may be defined by the processing rule.

The processing unit 302 may also processing the exchange request.Processing the exchange request may include identifying exchange amountsof the universal virtual currency and the real currency by applying therate of exchange to the exchange value, adjusting the associated valueof universal virtual currency in the consumer account information basedon the exchange amount of the universal virtual currency, andtransmitting the exchange amount of real currency to a financial accountbased on the received account routing information. In one embodiment,transmitting the exchange amount of real currency to a financial accountmay include transmitting the real currency through traditional paymentrails. In a further embodiment, the traditional payment rails mayinclude ACH transfer or wire transfer.

Techniques consistent with the present disclosure provide, among otherfeatures, systems and methods for distributing content to devices,initiating financial transactions, processing electronic financialtransactions using a payer device and pay codes, and indirectlycontrolling websites. While various exemplary embodiments of thedisclosed system and method have been described above it should beunderstood that they have been presented for purposes of example only,not limitations. It is not exhaustive and does not limit the disclosureto the precise form disclosed. Modifications and variations are possiblein light of the above teachings or may be acquired from practicing ofthe disclosure, without departing from the breadth or scope.

What is claimed is:
 1. A system for facilitating currency exchangingusing a universal virtual currency, comprising: a database configured tostore a plurality of currency exchange rules, wherein each currencyexchange rule is associated with at least a virtual currency and one ormore real currencies; a receiving device configured to receive atransaction request for a currency exchange from a consumer, wherein thetransaction request includes at least an amount of a first real currencyand indicates a second real currency; a processor configured to identifya first currency exchange rule stored in the database where theassociated one or more real currencies includes at least the first realcurrency, identify a second currency exchange rule stored in thedatabase where the associated one or more real currencies includes atleast the second real currency, calculate a virtual currency amountbased on the identified first currency exchange rule and the amount ofthe first real currency included in the received transaction request,and calculate an amount of the second real currency based on theidentified second currency exchange rule and the calculated virtualcurrency amount; and a transmitting device configured to transmit atleast the calculated amount of the second real currency.
 2. The systemof claim 1, wherein the first currency exchange rule and the secondcurrency exchange rule are the same currency exchange rule.
 3. Thesystem of claim 1, wherein the transaction request includes at least afunding source and a destination source.
 4. The system of claim 3,wherein the processor is further configured to initiate a financialtransaction for payment of the amount of the first real currency fromthe funding source.
 5. The system of claim 3, wherein transmitting atleast the calculated amount of the second real currency includesinitiating a financial transaction for payment of the calculated amountof the second real currency to the destination source.
 6. The system ofclaim 1, wherein transmitting at least the calculated amount of thesecond real currency includes transmitting a notification to theconsumer that includes at least the calculated amount of the second realcurrency.
 7. The system of claim 6, wherein the notification furtherincludes one or more exchange rates based on the identified firstcurrency exchange rule and/or the identified second currency exchangerule.
 8. The system of claim 6, wherein the notification furtherincludes the calculated virtual currency amount.
 9. The system of claim6, wherein the notification is transmitted as a response to the receivedtransaction request.
 10. The system of claim 1, wherein the transactionrequest is formatted pursuant to ISO
 8583. 11. A method for facilitatingcurrency exchanging using a universal virtual currency, comprising:storing, in a database, a plurality of currency exchange rules, whereineach currency exchange rule is associated with at least a virtualcurrency and one or more real currencies; receiving, by a receivingdevice, a transaction request for a currency exchange from a consumer,wherein the transaction request includes at least an amount of a firstreal currency and indicates a second real currency; identifying, by aprocessing device, a first currency exchange rule stored in the databasewhere the associated one or more real currencies includes at least thefirst real currency; identifying, by the processing device, a secondcurrency exchange rule stored in the database where the associated oneor more real currencies includes at least the second real currency;calculating, by the processing device, a virtual currency amount basedon the identified first currency exchange rule and the amount of thefirst real currency included in the received transaction request;calculating, by the processing device, an amount of the second realcurrency based on the identified second currency exchange rule and thecalculated virtual currency amount; and transmitting, by a transmittingdevice, at least the calculated amount of the second real currency. 12.The method of claim 11, wherein the first currency exchange rule and thesecond currency exchange rule are the same currency exchange rule. 13.The method of claim 11, wherein the transaction request includes atleast a funding source and a destination source.
 14. The method of claim13, further comprising: initiating, by the processing device, afinancial transaction for payment of the amount of the first realcurrency from the funding source.
 15. The method of claim 13, whereintransmitting at least the calculated amount of the second real currencyincludes initiating, by the processing device, a financial transactionfor payment of the calculated amount of the second real currency to thedestination source.
 16. The method of claim 11, wherein transmitting atleast the calculated amount of the second real currency includestransmitting a notification to the consumer that includes at least thecalculated amount of the second real currency.
 17. The method of claim16, wherein the notification further includes one or more exchange ratesbased on the identified first currency exchange rule and/or theidentified second currency exchange rule.
 18. The method of claim 16,wherein the notification further includes the calculated virtualcurrency amount.
 19. The method of claim 16, wherein the notification istransmitted as a response to the received transaction request.
 20. Themethod of claim 11, wherein the transaction request is formattedpursuant to ISO 8583.